Unified Modelling Language (UML) can be used to describe systems. A common use of UML is to provide a description of a system that is to be implemented in software. Traditionally, an analyst will study a system that is proposed for implementation in software and produce a UML description of the system. A programmer will then work from the UML description provided by the analyst in order to produce software that implements the system whilst complying with the constraints of the particular architecture of the computing hardware that is to execute the software. Some examples of such constraints are the amount of memory in the computing hardware and the number and processing speed of the processors in the computing hardware.
MIL provides a range of methods for describing systems. One such method is the use of activity diagrams. An activity diagram describes a system in terms of activities and control flows between the activities. The control flows are represented by a set of primitives, and these primitives will now be described by reference to FIGS. 1 to 6.
FIG. 1 shows an activity diagram primitive that is called the fork node. Here a fork node 10 describes the relationship between activities 12, 14 and 16. The fork node 10 indicates that upon completion of activity 12, activities 14 and 16 are commenced concurrently.
FIG. 2 shows an activity diagram primitive that is called the join node. Here, a join node 18 describes the relationship between activities 20, 22 and 24. The join node 18 indicates that upon completion of both activities 20 and 22, activity 24 is commenced. Thus, the join node primitive has a synchronising effect, in that it allows an activity to commence only after a plurality of other activities have finished.
FIG. 3 shows an activity diagram primitive that is called the decision node. Here, a decision node 26 describes the relationship between activities 28, 30 and 32. The decision node 26 indicates that upon completion of activity 28, only one of activities 30 and 32 is commenced. Which one of activities 30 and 32 is commenced is decided by a logical condition associated with the decision node 26. For example, whether or not a particular parameter of the system is greater or less than some predetermined value.
FIG. 4 shows an activity diagram primitive that is called the merge node. Here, a merge node 34 describes the relationship between activities 36, 38 and 40. The merge node 34 indicates that activity 40 is commenced as soon as either one of activities 36 and 38 is completed.
FIG. 5 shows an activity diagram primitive that is called the initial node. The initial node indicates the start of the system. Here, an initial node 42 indicates that the system begins with the performance of activity 44.
FIG. 6 shows an activity diagram primitive that is called the final node. The final node indicates the end of the system. Here, a final node 46 indicates that the system ends after the performance of activity 48.
So far, nothing has been said about the nature of the activities that the primitives connect. These activities are almost infinitely diverse in nature. Often, an activity will be complex in the sense that it might be capable of being described by its own activity diagram. This document will discuss multiprocessor systems that are suitable for conducting wireless communications and in that context examples of activities are:                carrying out a direct memory access (DMA) procedure for moving data from one place to another.        performing a fast Fourier transform (DMA) on a digital time domain signal.        performing a cross correlation of two digital time domain signals.        calculating a cyclic redundancy checksum (CRC) for a data sequence,        